home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 11779 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.0 KB
  1. Path: keats.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++
  4. Subject: Re: C/C++ knocks the crap out of Ada
  5. Date: 15 Mar 1996 20:00:08 -0800
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4idec8INNm22@keats.ugrad.cs.ubc.ca>
  8. References: <00001a73+00002504@msn.com> <4iah20$p7k@saba.info.ucla.edu> <4ictel$18v@tpd.dsccc.com> <4id4cc$1rau@saba.info.ucla.edu>
  9. NNTP-Posting-Host: keats.ugrad.cs.ubc.ca
  10.  
  11. In article <4id4cc$1rau@saba.info.ucla.edu>,
  12. Jay Martin <jmartin@cs.ucla.edu> wrote:
  13.  >kcline@sun132.spd.dsccc.com (Kevin Cline) writes:
  14.  >
  15.  >>Maybe, but I personally find it much easier to maintain lex & yacc
  16.  >>grammers which make the file syntax explicit, instead of trying to
  17.  >>divine the syntax from scanf statements scattered throughout a dozen
  18.  >>subroutines.
  19.  >
  20.  >If you have to parse something, fine use lex and yacc.  If it is
  21.  >simple I prefer to use simple IO statements of the language.  Parsing
  22.  
  23. Which is what the parser does. The difference is that the parser generator
  24. writes the program for you. Clue in!
  25.  
  26.  >is really only needed when there are nested structures in the text.
  27.  
  28. Not necessarily. You don't need recursion to build a grammar that is tricky to
  29. deal with.
  30.  
  31.  >As a user, I do not want to read a grammer for a text file format.
  32.  
  33. All text file formats that you come up with via hard-coded programming will
  34. have a grammar, whether you like it or not.
  35.  
  36.  >As a programmer annotated grammers do not do much for me either.
  37.  
  38. This may be your personal experience. Other people find grammars to be useful.
  39.  
  40.  >>The scanf programmers tend to define their input file syntax to make
  41.  >>it easy to parse, rather than easy to read, and then resist all
  42.  >>suggestions to extend the syntax for user convenience.
  43.  >
  44.  >I personally do not find complex text file formats as an exceptable
  45.  >user friendly method of input in this day and age.  Users should look
  46.  >at GUI's not goofy text files.  Thus, slight differences in the
  47.  
  48. You are flipping the subject.
  49.  
  50.  >flexiblity of file formats is really of little concern these days as
  51.  >no one should be really looking at them. Besides grammer style legacy
  52.  >text file formats I see little use for parsing besides writing your
  53.  >own C++ or Ada95 or other language compiler ( or pretty printer, etc).
  54.  >Something I am not planning to do anytime soon.  So has GUI's and huge
  55.  >languages really ruined the usefulness of parsing, or am I forgetting
  56.  >some important uses of parsers.
  57.  
  58. What do GUI's have to do with the thread you started? I thought it was about
  59. hand-coding scanners and parsers versus having it done for you from an 
  60. abstract spec. 
  61.  
  62. Huge languages have to be translated somehow. (What huge languages are we
  63. talking about? How do ``huge languages'' eliminate the usefulness of parsing?)
  64.  
  65. Look at the Macintosh; if you want to automate tasks, you have to do some
  66. meta-programming using something called Applescript. Looks like text!
  67.  
  68. I think this sort of discussion is very off-topic for comp.lang.*.
  69. -- 
  70.  
  71.